【AWS Amplify 노하우 시리즈】 1. 백엔드 프로젝트는 별도로 분리시킵시다

안녕하세요!ㅎㅎ Classmethod 컨설팅부 소속 김태우입니다.

저는 스타트업에 생태계에 관심이 많아서, 스타트업 기업에서 빠른 서비스 개발을 위해 활용할 수 있는 AWS AppSync 와 AWS Amplify 에도 관심이 많습니다. 그래서 평소에도 AppSync 나 Amplify 를 이용하여 사이드 프로젝트를 하고 있는데요, 이번에는 특히, Amplify 를 실제로 사용해보면서 느낀, 노하우가 될 만한 것들을 정리하는 블로그 시리즈를 작성해보려고 합니다.

본 시리즈에서는 Amplify 의 기초부분은 다루지 않고 어디까지나 Amplify 를 사용해보신 분들에게 도움이 될 만한 정보들만 요약해서 전달드리고자 하니, 기초부분에 대해서는 공식문서의 튜토리얼이나 다른 글들 을 참고해주세요 :)

오늘은 첫번째로, 백엔드 프로젝트는 별도로 분리시킵시다 라는 제목으로 글을 써보겠습니다!

그럼 시작하겠습니다! :)

백엔드를 분리시키라니??

AWS Amplify 공식 도큐먼트 를 읽다보면 자연스레 프론트엔드 프로젝트에 백엔드 프로젝트(좀 더 정확히는 amplify/ 폴더) 를 넣어두는 아래와 같은 구성을 머릿속에 떠올리시게 될 것 같습니다.

...
amplify/
src/
node_modules/
package.json
...

흔히 스타트업에서 백엔드 개발시에 가장 먼저 개발하게되는 것이 바로 프론트 측과 통신할 API 서버인데요, Amplify 를 활용하면 GraphQL Schema 를 작성하는 것만으로도 멋진 API 가 짜잔! 하고 금방 이용할 수 있게되어서 굉장히 매력적인 것 같습니다. 심지어 프론트랑 같은 프로젝트에 백엔드 리소스가 정의되어 있어서 프로젝트를 왔다갔다 할 필요도 없고 얼마나 좋은가요?!

그런데 갑자기 백엔드 프로젝트를 별도로 분리시키라니요...?

네..ㅎㅎ 경우에 따라서는 위의 생각이 맞을지도 모르겠습니다. 그런데, 보통 서비스 개발을 하면 앱개발 혹은 웹개발은 필수적이고, 그 뒤의 컨텐츠 관리나 회원관리 등을 위한 관리자용의 어드민 프로젝트도 함께 만드는 것이 일반적일 겁니다. 이런 경우, 앱 + 어드민 혹은 웹 + 어드민만 하더라도 이미 개발되어야할 클라이언트측의 플랫폼이 이미 두 종류가 넘어가게 됩니다.

심지어는 클라이언트용으로 iOS/Android/웹 플랫폼을 개발하고, 관리자용으로 마스터 어드민/XXX용 어드민/OOO용 어드민 등을 개발해야한다면, 각 플랫폼마다 백엔드 프로젝트를 일일이 다 세팅하실건가요?! 뭔가 통합된 하나의 리포지토리를 두고, 해당 (백엔드) 리포지토리에서 업데이트 된 것들만 pull 받아오고 싶은 생각이 드시나요?ㅎㅎ

이 외에도, 애초에 프론트와 백엔드는 관심사가 다르기에, 제가 생각하는 백엔드 프로젝트를 분리시킴으로서 얻는 이점은 아래와 같습니다.

백엔드 프로젝트를 분리시킴으로서 얻는 이점

1. 백엔드와 프론트의 Separation of Concern 을 실현하기 쉽다

AWS Amplify 에서 제공해주는 기능들은 매우 훌륭하고 간편하지만, 실제로 서비스 개발을 하다보면 Amplify 가 제공해주는 기능들만으로 모든 케이스가 충당되는 경우는 그렇게 흔하지 않을거라 생각합니다. 이런 경우에, 별도의 백엔드 프로젝트를 이미 분리시켜두었다면, 해당 프로젝트 내에서 custom-backend/ 와 같은 폴더를 두고, 그 아래에 관련 코드를 작성하시는 편이 훨씬 코드 관리하기에 용이할 것 같습니다. 이 때, 커스텀 백엔드가 Lambda 를 활용한 AppSync 의 custom resolver 를 개발하는 방식일 수도 있을것이고, 혹은 AppSync 와는 완전히 별개로 API Gateway + Lambda 등의 구성이나 AWS 이외의 서비스를 활용한 코드를 작성하시는 방법 등 다양한 방법으로 어프로치 할 수 있을 것 같습니다.

또한, 작성한 커스텀 코드의 테스트 코드를 작성하신다거나, seed-data 를 넣는다거나 하는 등의 작업을 하시기에도 백엔드 프로젝트가 별도로 분리되어 있는 편이 여러가지 관점에서 더 직관적이고, 관리하기 쉬운 형태가 될 것이라 생각합니다.

2. 복수명의 팀원이 함께 작업하기 용이하다

서비스 개발을 현재 혼자만 하고 있다고 하더라도, 계속해서 혼자서만 개발할 것을 염두에 두고 개발하는 분은 정말 드물 것 같습니다. 결국 뭔가를 제대로 만들기위해서는 혼자서 개발하기보다는 팀을 꾸려서 개발하는 경우를 염두에 두어야하는데, 이런 경우에도 백엔드 프로젝트를 분리시키는 것이 당연히 직관적이고 관리하기에도 편리합니다.

특히, 백엔드 프로젝트를 Github 등에 push 해 놓고, push 될 때마다 Slack 등의 협업용 메신저에 알림이 오게끔 설정해두시면, 다른 팀원들이 백엔드 프로젝트에서 무언가가 수정되었다는 사실을 금세 알아차릴 수 있을 것이고, 본인이 담당하고 있는 프론트 프로젝트에서 amplify pull 해야한다는 사실을 쉽게 알아차릴 수 있습니다.

3. 추후에 백엔드 프로젝트를 마이그레이션하기에도 더 편리하다

제 개인적인 견해로는 AWS Amplify 는 초기 스타트업의 서비스 개발에는 굉장히 큰 효율성과 스피드를 더해줄 수 있는 훌륭한 도구이지만, 어느정도 서비스가 안정화되고 기능이 고도화 되어감에 따라 특정 시점에서 탈 Amplify 화를 해야한다고 생각합니다. 이 때, 백엔드 프로젝트가 분리되어있지 않다면 점진적으로 마이그레이션을 프론트엔드 프로젝트에 백엔드 feature 브랜치를 파서 작업을 해야하는 뭔가 깨림칙한 상황이 벌어질 가능성이 높습니다. 1번에서 언급한 관심사의 분리(Separation of Concern) 에도 어느정도 포함되는 내용이지만, 코드의 형상관리라는 관점에서 프론트 프로젝트에 백엔드 commit 로그를 쌓는 것이 추후에 커밋로그의 컨벤션을 만들어감에 있어서도 좋지 않다는 점도 기술하고 싶었습니다.

그래서 어떻게하면 되는데요?

위와 같은 이유에 공감하고 백엔드를 분리시키셨다고 마음먹으셨다면 백엔드를 분리시키는 것은 상당히 간단합니다. 앞으로 자주 사용하게 될 아래의 커맨드

• amplify push
• amplify pull
• amplify codegen

에만 익숙해지시면 됩니다.

Amplify 에서 정의한 리소스는 AWS 상에 배포되고 관리되므로, 추가적인 프로젝트를 만드신다고 하더라도 amplify pull 만 해주시면 즉시 해당 Amplify 프로젝트와 연계됩니다.

먼저, 새로운 프로젝트를 만들어봅시다.

$ mkdir amplify-backend
$ cd amplify-backend
$ amplify pull

amplify init 을 하지 않아도 amplify pull 만 입력하셔도 AWS profile 을 선택하고 Amplify 프로젝트를 선택하는 과정도 알아서 해줍니다.

그다음에는 방금 만든 amplify-backend 에서 뭔가를 수정해서 amplify push 해주시고, 기존의 프론트엔드 프로젝트에서 amplify pull & amplify codegen 만 해주면 프론트엔드 프로젝트와 백엔드 프로젝트가 분리되었다는 사실을 알 수 있습니다. 이후로는 프론트엔드 프로젝트에서는 절대 백엔드 설정부분은 건드리지 않도록하고, 백엔드 프로젝트에서만 작업하도록 하는 컨벤션을 만들어두면 더욱 직관적이고 효율적으로 프로젝트를 진행할 수 있을 것 같습니다.

프론트엔드 프로젝트 설정방법

백엔드 프로젝트의 설정이 완료되었다면, 프론트 프로젝트에서 amplify/ 폴더를 삭제합니다. 그리고 다시 amplify pull 을 하면 백엔드에서 설정했던 과정과 그대로를 똑같이 진행하게되는데요, 이 때, amplify pull 의 마지막 단계에서 Do you plan on modifying this backend? 라고 물어보게 됩니다. 이 때, No 를 선택하시면 amplify/ 폴더가 생성되지 않습니다. 즉, 백엔드는 별도로 관리하겠다는 선언이 됩니다.

이렇게 되면 amplify codegen 이 동작하지 않게되는데요, 프로젝트의 최상단에서 아래와 같이 schema.json 을 다운로드 (혹은 최신화) 합니다.

$ aws appsync get-introspection-schema --api-id ${APPSYNC_APP_ID} --format JSON schema.json

이 schema.json 파일이 있으면 amplify/ 폴더가 없어도 codegen 이 가능하게 됩니다. 아래와 같이 amplify codegen add 를 실행하고 적절한 선택을 해주면 세팅은 완료입니다!

$ amplify codegen add

최초 세팅이므로 codegen 의 설정을 해줘야하기에 add 를 붙였지만, 이후에 백엔드가 업데이트 될 때마다 아래 명령어 두가지면 프론트에서 백엔드의 변경된 내용을 즉시 반영할 수 있게됩니다.

$ aws appsync get-introspection-schema --api-id ${APPSYNC_APP_ID} --format JSON schema.json
$ amplify codegen

노하우 공유

위의 방식대로 프론트엔드 프로젝트를 설정하는 것도 괜찮은 방법이지만, 사실 저는 amplify pull 의 마지막 단계에서 Do you plan on modifying this backend? 에서 Yes 를 선택하는 쪽을 선호합니다.

그 이유는 아래의 두가지 인데요,

1. 백엔드 설정이 그대로 보이게되는 환경으로 프로젝트가 구성되더라도, 프론트 프로젝트에서는 amplify/ 폴더를 건드리지 않기로하는 컨벤션을 정해두기만 하면 문제가 없다는 점
2. 프론트 개발자에게 amplify codegen 으로 생성된 복잡한 코드가 아닌, GraphQL 스키마 그 자체를 공유하고 싶을 경우, amplify/ 폴더 내부의 backend/api/${API명}/schema.graphql 을 보게끔 할 수 있다는 점

특히 schema.graphql 에 각종 필드에 대한 주석 및 설명 등을 달아놓으면, 스키마를 작성한 의도 등이 고스란히 추후에도 확인할 수 있게되어서 프론트 개발자와 백엔드 개발자간의 협업이 더욱 잘 되도록 도와주는 역할을 할 수 있습니다.

글을 맺으며

저는 AWS Amplify 에 대해 올초부터 다시 눈여겨 보고 있습니다. 스타트업의 빠른 서비스 개발에 핵심적인 기능들만 잘 모아둔 느낌이지만, 제대로 활용할 줄 못하면 아쉬움만 남기고 다른 어프로치를 찾아보는 경우가 흔합니다. 하지만 제가 직접 Amplify 로 사이드 프로젝트를 진행하면서 느꼈던 것은 생각보다 꽤 많은 기능을 잘 서포트 해주고 있었고, 특히 협업이라는 관점에서도 스타트업 환경에서 필요로 하는 수준까지는 어느정도 잘 지원해주고 있다고 생각합니다.

협업을 더욱 잘하기 위해서는 관심사를 분리시켜서 서로 독립적인 작업을 할 수 있는 환경을 세팅하는 것이 중요합니다. Amplify 를 사용함에 있어서도 프론트와 백엔드를 분리시켜서 개발해보는 것은 어떨까요?

이상, 컨설팅부의 김태우였습니다! :D